PR의 목적이 무엇인가요?

• 알림 전송 과정에서의 예외 발생으로 인한 롤백을 방지하기 위한 비동기 및 트랜잭션 격리 추가
• 참여에서의 알림 메시지에 모임 이름을 추가(누가 어떤 모임에 참여했음 / 취소했음)하여 사용자가 알림 메시지만 보고 어떤 모임인지 바로 파악할 수 있도록 수정

이슈 ID는 무엇인가요?

• 알림 메시지 형식 수정 및 비동기 처리 추가 #724

설명

배경

용어를 먼저 정리해보자면, 전체 알림 작업은 다음 순서로 진행됩니다.

• 모임 등에서의 서비스 로직 -> 알림 대상자 조회 -> 이 대상자와 알림을 DB에 저장(알림 센터용) -> 회원별 구독 정보 조회 후 실제 푸시 알림을 전송할 회원 필터링 -> 필터링된 회원의 FCM 토큰 조회 -> 실제 전송

앞으로는 모임 생성 / 참여 등의 작업을 서비스 작업, 알림 대상자 조회~ 부터를 알림 작업, 실제 전송을 알림 전송으로 표현하겠습니다.

기존 구조

기존의 구조는 다음과 같습니다.

이 구조에서 생각할 수 있는 문제는,

1. 서비스 작업과 알림 대상자 조회 작업이 같은 트랜잭션으로 묶여있습니다. 따라서 알림 대상자 조회 작업이 실패하면 서비스 작업도 실패하게 됩니다.(어제 QA에서 발생한 베팅에서만 채팅이 안되는 문제)
2. 회원 알림 저장과 구독, FCM 토큰 조회 작업도 하나의 트랜잭션으로 묶여있어 토큰 및 구독 조회에서 문제가 발생하면 알림 저장 작업도 실패하게 됩니다.
3. 알림 대상자 조회 / 구독과 토큰 조회 작업은 순수 read-only 작업인데, 기존 트랜잭션을 사용하다보니 이 조회 과정에서도 writer DB를 사용하고 있습니다.

알림의 전체 흐름에서 가장 중요하게 이루어져야 하는 작업은 서비스 작업과 회원별 알림을 저장하는 작업이라고 생각하는데요, 그러면 다음과 같은 조건을 만족해야 한다고 생각했습니다.

1. 서비스 작업은 알림 작업과 무관하게 마무리 되어야 한다.
2. 알림 작업은 서비스 작업이 정상적으로 마무리(= 트랜잭션 커밋) 되었을 때 진행되어야 한다.
3. 마찬가지로 회원별 알림 저장 작업은 실제 알림 전송과 무관하게 마무리 되어야 하고, 실제 알림 전송은 회원별 알림 저장 작업이 정상적으로 마무리 되었을 때 진행되어야 합니다.

수정된 구조

따라서 위의 관점으로 전체 구조를 아래 사진과 같이 수정했습니다.

비동기 처리는 Async 어노테이션을 사용해도 되지만, 이 경우 기존 작업이 마무리 되었는지(= 트랜잭션이 커밋되었는지)의 여부와 무관하게 비동 기 실행이 될 수 있기에 TransactionalEventListener를 이용해서 기존 작업이 커밋되었을 때(TransactionPhase.AFTER_COMMIT) 나머지 작업이 진행되도록 합니다.

바뀐 구조에서는 기존의 문제를 다음과 같이 해결합니다.

1. 서비스 작업과 나머지 알림 작업은 별도로 작동합니다. 따라서 알림 작업과 서비스 작업이 독립적으로 작동하니, 알림에서의 예외가 발생해도 서비스 작업에는 영향이 없습니다.
2. 회원 알림 저장과 이후 작업도 별도로 작동합니다. 따라서 토큰 / 구독 조회 및 알림 전송에서 문제가 발생해도 회원 알림은 정상적으로 저장됩니다.
3. 알림 대상자 조회 / 구독과 토큰 조회 작업은 Read-Only를 지정하여, 쓰기 DB를 사용하는 기존 방법과 달리 읽기 DB를 사용하게 됩니다.
   물론 지금 정도의 트래픽에서는 쓰기 DB만 사용해도 크게 문제는 없다고 느껴지나, 성능의 관점이 아닌 상황에 맞는 적절한 DB를 사용한다는 점에서의 의의가 있다고 생각합니다

비동기 처리에 대한 테스트 커밋은 별도 링크로 남겨둘게요 ~ (링크1, 링크2)

질문 혹은 공유 사항 (Optional)

알림 작업은 정말 끝이 없네요.. 알림쪽은 아무래도 제가 맡아서 진행한 만큼 전체 맥락 파악이 쉽지는 않을 것이라고 생각합니다.
그래서 최대한 풀어쓴다고 했는데, 그럼에도 이해가 안가는 부분이 있다면 편하게 질문 주세요!